<script>on mouseUpvisual scroll leftgo cd 2end mouseUp</script>
</part>
<part>
<id>2</id>
<type>button</type>
<visible> <true /> </visible>
<reserved5> 0 </reserved5>
<reserved4> 0 </reserved4>
<reserved3> 0 </reserved3>
<reserved2> 0 </reserved2>
<reserved1> 0 </reserved1>
<enabled> <true /> </enabled>
<rect>
<left>36</left>
<top>310</top>
<right>136</right>
<bottom>332</bottom>
</rect>
<style>roundrect</style>
<showName> <true /> </showName>
<highlight> <false /> </highlight>
<autoHighlight> <true /> </autoHighlight>
<sharedHighlight> <true /> </sharedHighlight>
<family>0</family>
<titleWidth>0</titleWidth>
<icon>0</icon>
<textAlign>center</textAlign>
<font>Chicago</font>
<textSize>12</textSize>
<textStyle>plain</textStyle>
<name>Try Me</name>
<script>on mouseUpglobal gXCMDErrorsysDebuggerBreak "hit 'g' and return to exit MacsBug"if gXCMDError is not empty then answer gXCMDErrorend mouseUp</script>
<text><span class="style3">bout</span><span class="style1"> This XCMD causes a debugger break, though not to the HyperTalk debugger, but to the system debugger (if one is installed). This is designed for people who want to mess with MacsBug from a HyperTalk script. This can be nice for writing XCMDs and such without putting breaks in the XCMD code.</span><span class="style3">Parameters</span><span class="style1"> The one parameter is optional, and is the message with which the debugger will respond. </span><span class="style3">Error Messages</span><span class="style1"></span><span class="style4">Error: Debugger not installed</span><span class="style7"></span><span class="style1"> This is what you'll get if you try this XCMD without something like MacsBug installed.</span><span class="style3">Notes</span><span class="style1"> This has really only been tested with MacsBug, but it </span><span class="style9">should</span><span class="style1"> work with debuggers like TMON as well. That's the theory, anyway.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>0,40,40,40</text>
</content>
<name>sysDebuggerBreak</name>
<script></script>
</card>
card_7582.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<script>on mouseUpglobal gXCMDErrorput selectedPrinter() into ThePrinterif gXCMDError is not empty then exit mouseUpif the number of items in ThePrinter = 2 thenanswer "Your system will attempt to print to the" && item 1 of ThePrinter¬&& "named “" & item 2 of ThePrinter & "”." --∆elseanswer "Your system will attempt to print to the device “" ¬& item 1 of ThePrinter & "”." --∆end ifend mouseUp</script>
<text><span class="style3">bout</span><span class="style1"> This XFCN returns the type of printer that is currently selected, and, if possible, the name of that printer. Item 1 of the result will contain the type of printer selected and, if available, item 2 will contain the name of the printer. So, for example, if the currently selected printer is a LaserWriter named "Peach", then this XFCN would return "LaserWriter,Peach". If no printer is selected, the XFCN will return "No printer selected."</span><span class="style3">Parameters</span><span class="style1"> No parameters are passed to this XFCN.</span><span class="style3">Error Messages</span><span class="style1"></span><span class="style4">Error: Could not get the 'STR ' resource from the System</span><span class="style1"> For some unknown reason, the System file could not be properly accessed. This is possible in extreme low memory conditions and if the System file is corrupt.</span><span class="style3">Notes</span><span class="style1"> This XFCN does not go out onto the network in any way. What it does is check a resource in the System file for the type of printer that is selected, and then attempts to open the printer driver for the name of the printer. Thus, this XFCN tells nothing about whether or not it will be possible to print to the selected printer, only what printer the operating system will try to print to.</span></text>
</content>
<name>selectedPrinter()</name>
<script></script>
</card>
card_7211.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style3">bout</span><span class="style1"> This XFCN compares every pixel of one card picture to every pixel of another card picture. If they are the same, it returns true, otherwise it returns false. </span><span class="style3">Parameters</span><span class="style1"> Both the first and second parameters should be strings that specify valid cards. Remember that strings must be quoted, so to check card "foo1" against card "foo2" you'd call it as</span><span class="style4">sameCardPicts("card" && quote & "foo1" & quote, "card" && quote & "foo2" & quote)</span><span class="style3">Error Messages</span><span class="style1"></span><span class="style4">Error: Not enough memory</span><span class="style1"> This XFCN has to make a copy of the cardA bitmap, and needs to allocate however much memory that will take. (About 22K in the case of a 512x342 card). If this gives you trouble, increase your partition</span><span class="style3">Notes</span><span class="style1"> This compares just the card picture. If the backgrounds are different, this will not know. Nor will it notice if the buttons or fields are different.</span></text>
</content>
<name>sameCardPicts()</name>
<script></script>
</card>
card_6938.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style1">ere is </span><span class="style9">an example </span><span class="style10">of some </span><span class="style11">hip and funky styled text</span><span class="style12">. All kinds of </span><span class="style13">weird and </span><span class="style14">wacky </span><span class="style12">stuff. </span><span class="style15">H'okay?</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>0,117,255,255</text>
</content>
<content>
<layer>background</layer>
<id>4</id>
<text><span class="style3">bout</span><span class="style1"> This XCMD will copy the contents of one field into another field, will all style information. This is like "put" in HyperTalk in that it will destroy whatever was in the destination field. The XCMD will go from one card to another if requested. That is, you can copy text from card field 1 on card "red" and put it into background field 3 on card "orange".</span><span class="style3">Parameters</span><span class="style1"> The first parameter specifies the field to copy the text from, and the second specifies the field to which to copy the text. Any identifier that HyperTalk accepts should be acceptable to the XCMD. Remember, you have to quote a string to pass it to an XCMD. Thus, to use a field name, you'll have to pass it something like </span><span class="style4">"card field" && quote & "<fieldName>" & quote</span><span class="style1">. The third parameter is optional, and specifies the card on which the destination field resides. If this parameter is omitted, the XCMD assumes that the destination field is on the current card.</span><span class="style3">Error Messages</span><span class="style1"></span><span class="style4">Error: Invalid fromField specification</span><span class="style7"></span><span class="style1"> This means that whatever was passed in as the first argument is not a valid description of an actual field.</span><span class="style7"></span><span class="style4">Error: Invalid toField specification</span><span class="style7"></span><span class="style1"> Same as above, except that this applies to the second argument.</span><span class="style3">Notes</span><span class="style1"> The most important thing to note is that if a third parameter is supplied, the XCMD will cause the HyperCard to go to that card. If you don't want this to be visible, you should lock the screen, push the current card, call the XCMD, pop the stack, and unlock the screen.</span></text>
</content>
<name>putWithStyle</name>
<script>on closeCardput empty into cd fld 2end closeCard</script>
</card>
card_6678.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style3">bout</span><span class="style1"> This XCMD takes a path name to a PICT file and copies that file into a PICT resource, either in the current stack or in another stack. The resource can be renamed as well. This XCMD is useful for working with BungDabba's "ColorizeHC" XCMD.</span><span class="style3">Parameters</span><span class="style1"> The first parameter should be the full pathname to a PICT file. The second parameter is optional, and is the name for the PICT resource once it has been imported. If this parameter is not supplied, the name of the file is used. The third parameter is also optional. If omitted, the PICT resource will be added to the current stack. If a full pathname to another stack is supplied, the PICT resource will be written to that file.</span><span class="style3">Error Messages</span><span class="style1"> Mucking around with HFS means there is a plethora of possible errors:</span><span class="style4">Error: The input file is not a PICT file</span><span class="style1"> The full pathname supplied does not point to a PICT file. Check the first parameter.</span><span class="style4">Error: Duplicate resource not overwritten</span><span class="style1"> If there is a PICT resource in the target stack that has the same name and the user does not want it over-written, this error is returned.</span><span class="style6"></span><span class="style4">Error: Not enough memory</span><span class="style1"> This is what you'll get if you aim the XCMD at a PICT that is too large to read all at once. Try upping your HyperCard partition, or using a smaller PICT.</span><span class="style4">Error: Bad file nameError: File not foundError: No such volume</span><span class="style1"> These errors likely means the pathname passed in either the first or third parameter is not an actual pathname. Check your input.</span><span class="style4">Error: I/O error</span><span class="style1"> This means there was some error in the device or driver.</span><span class="style4">Error: Too many files open</span><span class="style1"> This is probably caused by a low-memory situation.</span><span class="style4">Error: Software volume lockError: Hardware volume lockError: Disk full</span><span class="style1"> All of these mean more or less what they sayΓÇösomething prevented writing to the target stack.</span><span class="style4">Error: OS error <###></span><span class="style1"> Some other error I haven't forseen. You'll have to dig up a table.</span><span class="style3">Notes</span><span class="style1"> It is possible to attempt to add a PICT to a stack that has a PICT with the same name. In this case, a dialog will appear, asking if it is okay to delete the current PICT. HyperCard 2.1 introduced a new property, the </span><span class="style4">lockErrorDialogs</span><span class="style1"> (see the HC 2.1 "New Features Guide" for a complete description). The upshot of this is that it prevents dialogs when errors occur. If the lockErrorDialogs is true, the confirmation dialog will not be presented, and the XCMD will write over the old resource. The ID number for the resource is picked by the XCMD.</span></text>
</content>
<name>PICTtoRsrc</name>
<script></script>
</card>
card_6600.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style3">bout</span><span class="style1"> This XFCN provides a simple way to implement buttons of irregular shape. It takes a point and a rect and checks to see if the point hits a region inside the rect. This amounts to checking to see if a black pixel was hit. In addition, the XFCN can be told to check for hits </span><span class="style3">inside</span><span class="style1"> any area enclosed by black pixels. So, for example, it can sense hits inside the circle to the left. The XFCN can also briefly flash the graphic to simulate autohiliting of normal buttons.</span><span class="style3">Parameters</span><span class="style1"> The first parameter should be a point, and the second a rect. The third parameter is optional and defaults to true. If it is true, the XFCN will briefly invert the region. The fourth parameter is also optional, and defaults to false. If it is true, the XFCN will sense hits that are inside the graphic. If false, it does not.</span><span class="style3">Error Messages</span><span class="style1"></span><span class="style4">Error: Could not allocate the first buffer</span><span class="style1"> The XFCN has to allocate a buffer to copy the rect into. If this error message is given, try using a smaller rect.</span><span class="style4">Error: Could not create the first region</span><span class="style1"> The XFCN was unable to make a region from the buffer. Again, this is probably due to low memory.</span><span class="style4">Error: Could not allocate the second buffer</span><span class="style1"> If "sense inside" is true, the XFCN has to allocate a second buffer (for a SeedFill for you techies), which requires more memory. Try a larger partition or a smaller rect.</span><span class="style4">Error: Could not create the second region</span><span class="style1"> Again, the second region is for "sense inside" hits, and is probably a memory problem.</span><span class="style3">Notes</span><span class="style1"> Note that this XFCN takes a point, not necessarily a mouse click. That may be useful to someone out there. This can be a memory hog if the rect passed is large and "sense inside" is true. (For a whole 512x342 card, for example, it will need about 44K.) But for small rects, this is really quite reasonable.</span></text>
</content>
<name>hitRegion()</name>
<script></script>
</card>
card_6398.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<script>on mouseUpglobal gXCMDErrorput empty into cd fld 1put systemPath() into PathNameput "• You have the following control panels installed:" ¬& return into cd fld 1put findTypes(PathName,f,t,f,"cdev") into ThePanelsif gXCMDError is not empty thenanswer gXCMDErrorend ifrepeat with LineCnt = 1 to the number of lines in ThePanelsput lastItem(":",line LineCnt of ThePanels) into ¬line LineCnt of ThePanelsend repeatif the number of lines in ThePanels > 16 thenset the style of cd fld 1 to "Scrolling"end ifput ThePanels after cd fld 1end mouseUp</script>
<text><span class="style3">bout</span><span class="style1"> This XFCN is a bit complicated in its usage and parameters, but the basic concept is simple. This XFCN will search a directory (and all its subdirectories) for files of the types specified. The XFCN can search for up to 12 different file types. Additional features: This XFCN can return type and creator codes with each file that it finds, it can spin the beach ball cursor while it searches, it can use System 7 catalog searches if desired (see "Notes" below), and the search can be canceled by issuing a command-period (though this will cancel the script that is executing as well). The output of this XFCN is a return-delimited list of full pathnames, with creator and type codes if requested. For example, it might return:</span><span class="style4">HD:System Folder:Control Panels:CaptureHD:System Folder:Control Panels:InUse</span><span class="style1">or, if codes are requested:</span><span class="style4">Captcdev,HD:System Folder:Control Panels:CaptureInUscdev,HD:System Folder:Control Panels:InUse</span><span class="style1">The file's creator code will be chars 1 through 4 of the line, and the file's type will be chars 5 through 8. This XFCN is reasonably fast, but your mileage may vary. See "Notes" for more information on this.</span><span class="style3">Parameters</span><span class="style1"> The first parameter should be the full pathname of the directory to be searched. Remember, names for directories end in colons. (Such as "HD:System Folder:") The second parameter determines whether or not the XFCN returns creator and type codes. If true, the codes are returned; if false, they are not. The third parameter determines whether or not the XFCN is to spin the beach ball cursor while it searches. This slows down the XFCN a little, but should normally by done to give good feedback to the user. If true, the ball will spin; if false, it will not. The fourth parameter tells the XFCN whether or not it should try to use a System7 "catalog" search. (See "Notes".) If this is false, the XFCN will try a catalog search, otherwise it will not. The remaining parameters should be four-character strings which specify file types. If a string of longer than four characters is passed, the string will be truncated to four characters.</span><span class="style3">Error Messages</span><span class="style1"></span><span class="style4">Error: Bad volume name</span><span class="style7"></span><span class="style1"> This will be returned if the first item in the colon-delimited pathname does not designate an accessible volume.</span><span class="style7"></span><span class="style4">Error: Not enough memory to begin</span><span class="style7"></span><span class="style1"> Since the return strings can be large, this XFCN allocates memory in chunks of 10K. If it can't get this much right away, it will return this message.</span><span class="style7"></span><span class="style4">Error: Invalid directory</span><span class="style7"></span><span class="style1"> This means the initial pathname does not indicate a folder that the XFCN can find.</span><span class="style4">Error: Search cancelled by user</span><span class="style7"></span><span class="style1"> If the user presses command-period along the way, the search will be cancelled and this will be placed in gXCMDError. However, the XFCN will not return an error. Rather, it will return all the files it had found up to that point.</span><span class="style7"></span><span class="style4">Error: Out of memory before completion</span><span class="style7"></span><span class="style1"> This will be loaded into gXCMDError if the XFCN runs out of memory before it can finish. What it could find will be returned as the result.</span><span class="style3">Notes</span><span class="style1"> This XFCN has two "modes" of searching: catalog search and brute-force search. Catalog searching is something new with System 7, and is blazingly fast--the "Find" command in the 7.0 Finder uses a catalog search. So why </span><span class="style3">not</span><span class="style1"> use catalog searching? There are a couple of problems with catalog searches. First, a catalog search always searches the entire volume, which may not be so fast. (The XFCN is smart enough to only return those files that are in the target directory, but it finds all of them on the volume.) Catalog searching is fast, but if you're looking in a folder with only one or two subfolders and only expect a few files to be found, a catalog search might actually be </span><span class="style3">slower</span><span class="style1">. The second thing that may make a catalog search slower is that a catalog search can only search for one type at a time. Thus, if you are searching for ten different file types, a catalog search will search your entire disk ten times. (This can still be faster, though, if the disk is large and you're searching a lot of it.) Thirdly, a catalog search is easier to "fool" than a brute-force search. For example, some extensions (such as AutoDoubler) change files' actual creator and type. This is normally not a problem, because they patch the "get info" type calls. However, a catalog search never makes such a call and will </span><span class="style3">not</span><span class="style1"> find files that have been changed in such a way. On the plus side, catalog searches are rippingly fast and much easier to "monitor" during execution--the cursor idling is more consistent, and a huge volume can be searched in seconds. But be aware that robustness can be sacrificed.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>0,380,653,1028</text>
</content>
<name>findTypes()</name>
<script>on closeCardput empty into cd fld 1set the style of cd fld 1 to "Transparent"end closeCard</script>
</card>
card_6130.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<script>on mouseUpput "ΓÇó Stack functions:" & return into cd fld 1 --Γêåput findHandlers(the script of this stack, t, "functions") after cd fld 1put return & return after cd fld 1put "ΓÇó Stack message handlers:" & return after cd fld 1 --Γêåput findHandlers(the script of this stack, f, "messages") after cd fld 1end mouseUp</script>
<text><span class="style3">bout</span><span class="style1"> This XFCN takes a script and finds all the handlers in that script. It will also return the starting and ending offsets of the handler within the script, and can "filter" to find just functions or just message handlers. It returns a return-delimited list of handlers, followed by the starting and ending offsets (separated by commas). The return would look something like this:</span><span class="style4">openStack,1,63closeStack,65,130suspendStack,132,186resumeStack,205,273</span><span class="style1">This works well in combination with compareLines() to determine whether a script has changed in functionality at all.</span><span class="style3">Parameters</span><span class="style1"> The first parameter should be a standard HyperTalk script. This XFCN will return strange, meaningless things otherwise. The optional, Boolean second parameter defaults to "true". If it is true, the character offsets are returned along with the handler names. The optional third parameter defaults to "both". This XFCN will find either functions (denoted with "function") or message handlers (denoted by "on") or both.</span><span class="style3">Error Messages</span><span class="style1"> There are no special error messages returned by this XFCN, but the XFCN can be "confused". If there is a handler in the script that is not "closed", that is, that has no "end" statement associated with it, this XFCN will be unable to find any more handlers, and will report the unclosed handler. The output in that case would look something like this:</span><span class="style3">Notes</span><span class="style1"> Again, this is basically simple string manipulation and could be done in HyperTalk without tremendous effort. This XFCN is faster, though, particularly for very long scripts with many handlers.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>0,224,301,301</text>
</content>
<name>findHandlers()</name>
<script>on closeCardput empty into cd fld 1end closeCard</script>
</card>
card_5878.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<script>on mouseUpglobal gXCMDErroranswer file "Check the data fork of which file?" --∆put it into PathNameif PathName is empty then exit mouseUpput fileDataSize(PathName) into NumberOfBytesif gXCMDError is not empty thenanswer gXCMDErrorexit mouseUpend ifset itemDelimiter to colonput lastItem(":",PathName) into FileNameanswer "The data fork of “" & FileName & "” is" && NumberOfBytes¬ --∆&& "bytes in size." --∆end mouseUp</script>
<text><span class="style3">bout</span><span class="style1"> This XFCN returns the size of a file's data fork, in bytes. This can be especially useful before using HyperTalk's "read" command.</span><span class="style3">Parameters</span><span class="style1"> This XFCN takes one parameter, the full pathname of the file to be examined.</span><span class="style3">Error Messages</span><span class="style1"> Because it's HFS, a plethora of error messages are possible.</span><span class="style4">Error: Bad file nameError: File not foundError: No such volume</span><span class="style2"></span><span class="style1"> These errors likely means the pathname passed is not an actual pathname. Check your input.</span><span class="style4">Error: File already open for writing</span><span class="style1"> This will happen if you aim the XFCN at an open file.</span><span class="style4">Error: I/O error</span><span class="style1"> This means there was some error in the device or driver.</span><span class="style4">Error: Too many files open</span><span class="style1"> This is probably caused by a low-memory situation.</span><span class="style4">Error: HFS error number <###></span><span class="style1"> Some other file system error occurred. You'll have to find a table.</span><span class="style3">Notes</span><span class="style1"> There is nothing spectacular about this XFCN, but I like to check files before I read from them.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>0,65,117,215</text>
</content>
<name>fileDataSize()</name>
<script></script>
</card>
card_5599.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style3">bout</span><span class="style1"> This XFCN takes two blocks of text and compares the lines in the two blocks, one at a time. It was designed to compare HyperTalk handlers to determine if they are different. If the two blocks of text are identical, the XFCN returns empty. Otherwise, it returns something like this:</span><span class="style4">These lines in A are not in B:3 to 69 to 911 to 13These lines in B are not in A:15 to 1517 to 20</span><span class="style1">The numbers in the return text are line numbers, which may be referenced by HyperTalk. </span><span class="style3">Parameters </span><span class="style1">The parameters passed should be two blocks of text. No line in either block should be larger than 200 characters.</span><span class="style3">Error Messages</span><span class="style4">Error: Not enough memory to complete</span><span class="style3"> </span><span class="style1">Because this XFCN has to make copies of the two blocks of text, it can use a fair amount of memory if the two blocks are large. </span><span class="style3">Notes </span><span class="style1">This XFCN is </span><span class="style3">not</span><span class="style1"> case-sensitive. In addition, it strips out additional spaces between the text. The two lines may not in fact be identical, then, in terms of case and spacing. However, the HyperTalk interpreter will act as if these lines are the same, and so will this XFCN. Yes, it is possible to do this with HyperTalk, but this is much faster.</span></text>
</content>
<content>
<layer>background</layer>
<id>8</id>
<text>0,219,219,219</text>
</content>
<name>compareLines()</name>
<script></script>
</card>
card_4966.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<script>on mouseUpif checkDebugger() is true thenanswer "Yes, you have a system debugger installed." --Γêåelseanswer "No, you don't have a system debugger installed." --Γêåend ifend mouseUp</script>
<text><span class="style3">bout</span><span class="style1"> This XFCN checks to see if a system debugger (such as MacsBug) is present. If so, it returns "true," otherwise it returns "false".</span><span class="style3">Parameters </span><span class="style1">No parameters are passed to this XFCN.</span><span class="style3">Error Messages </span><span class="style1">There are no special error messages returned by this XFCN.</span><span class="style3">Notes </span><span class="style1">For those techno-weenies wondering how on earth this works (because GetTrapAddress doesn't work on _Debugger and _DebugStr), there is an address in low memory (0x0120) that points to zero if no debugger is installed, and something else if one is. </span></text>
<text>This software is brought to you courtesy of BungDabba Productions. This software is provided "as is" without warranty of any kind, and BungDabba Productions expressly disclaims all implied warranties, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the results and performance of this software is assumed by you.You are free to use and distribute this stack, or any portion of this stack, anyway you see fit. </text>
</content>
<name>Stack Disclaimer</name>
<script></script>
</card>
card_4248.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text><span class="style1">ome conventions used in this stack:</span><span class="style3">Parameters</span><span class="style1">Parameters in descriptions and such adhere to the following conventions:<parameter>: Pass not literally the word "parameter", but some string.«parameter»: The parameter is a Boolean parameter, accepting either "true" or "false".[parameter]: The parameter is optional and need not be passed.para | meter : The XThing accepts either the literal "para" or the literal "meter"The following conventions should be supported by </span><span class="style3">all</span><span class="style1"> XThangs:</span><span class="style3">Syntax and copyright</span><span class="style1">Passing just "?" as a parameter returns syntax information and "!" returns copyright and version information. </span><span class="style3">Error reporting</span><span class="style1">Any errors will be reported in the HyperTalk global variable "gXCMDError". If one of these XThangs executes successfully, the gXCMDError global will be empty. Any error will also begin with the string "Error:".</span></text>
</content>
<name>Conventions</name>
<script></script>
</card>
card_2396.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text>This stack is a collection of XCMDs and XFCNs for HyperCard 2.x. It is provided as a freeware gift from BungDabba productions. They can be copied from this stack to your stacks with a utility such as ResExpress or ResEdit, or the Resource Mover provided in the Power Tools stack.The index displays a list of the XCMDs and XFCNs provided. By using the "XThangs" menu or the buttons on the index card, you can navigate through the stack. Each XThang has its own card which contains a description and some notes for that XThang. Hopefully, you will find one or more of these XThangs useful.Questions? Comments? Undocumented functionality (somtimes mistakenly referred to as "bugs")? Send electronic mail to "gt1991b@prism.gatech.edu".</text>
</content>
<name>About This Stack</name>
<script></script>
</card>
card_3998.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<text>Checks for the presence of a system debugger such as MacsBug.Compares two blocks of text line-by-line, noting differences.Returns the size of a file's data fork.Finds the handlers in a script, and notes their character offsets.Searches a directory and all its subdirectories for files of specified types.Allows hit-testing of irregularly-shaped graphics.Reads in a PICT file, making it into a resource.Puts the text from one field into another, retaining style information.Examines the card graphics of two cards to determine if they are identical.Returns the type (and possibly the name) of the currently selected printer.Causes a break to the system debugger (such as MacsBug) with a message or command.</text>
</content>
<content>
<layer>card</layer>
<id>16</id>
<text>Checks for the presence of a system debugger such as MacsBug.</text>
</content>
<content>
<layer>card</layer>
<id>24</id>
<text>Click on the name of an XThing to see a brief description. Click on a hilited name to go to more elaborate documentation of that XThing.</text>
</content>
<content>
<layer>background</layer>
<id>1</id>
<text>Index</text>
</content>
<content>
<layer>background</layer>
<id>2</id>
<text><span class="style1">1992 BungDabba Productions. All rights reserved.</span><span class="style17"></span></text>
</content>
<name>Control</name>
<script>on selectButton BtnNameset the hilite of cd btn BtnName to trueif BtnName = selectedButton() thenvisual zoom outgo cd BtnNameexit selectButtonend ifput BtnName into cd fld "Selected Button"put line (the number of the target) of cd fld "XThing Notes" ¬into cd fld "Description"end selectButtonfunction selectedButtonreturn cd fld "Selected Button"end selectedButton</script>
</card>
card_2865.xml
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE card PUBLIC "-//Apple, Inc.//DTD card V 2.0//EN" "" >
<script>on openStackanimatepass openStackend openStackon animateset cursor to nonelock screencolorizeHC "add","Don & The Windmill",the rect of cd btn 2unlock screenlock screencolorizeHC "add","Don & The Windmill",the rect of cd btn 4unlock screenlock screencolorizeHC "add","Don & The Windmill",the rect of cd btn 6unlock screenlock screencolorizeHC "add","Don & The Windmill",the rect of cd btn 1unlock screenlock screencolorizeHC "add","Don & The Windmill",the rect of cd btn 3unlock screenlock screencolorizeHC "add","Don & The Windmill",the rect of cd btn 5unlock screenlock screencolorizeHC "erase",the rect of cd btn 2colorizeHC "add","BungDabba Logo", the rect of cd btn 7unlock screenlock screencolorizeHC "erase", the rect of cd btn 4colorizeHC "add","SSL",the rect of cd btn 8unlock screenlock screencolorizeHC "erase", the rect of cd btn 6colorizeHC "add","BDX",the rect of cd btn 9unlock screenset cursor to normalshow cd fld 1end animateon closeCardlock screencolorizeHC "dispose"hide cd fld 1unlock screenend closeCardon suspendStacklock screencolorizeHC "dispose"unlock screenpass suspendStackend suspendStackon mouseUpgo nextend mouseUp</script>
